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Abstract 

The framework of promise theory offers an alternative way of understanding 
programming models, especially in distributed systems. We show that promise 
theory can express some familiar constructs and resolve some problems in program 
interface design, using fewer and simpler concepts than the Unified Modelling 
Language (UML). 



1 INTRODUCTION 

Current methodology in computer programming is based mainly on a popular inter- 
pretation of Object Orientation (OO) and software architecture modelling is usually 
done using the Unified Modelling Language (UML) |Rumbaughet al., 2004 1. Find- 



ing the right balance between top-down and bottom-up in program design is no easy 
matter, but OO and UML encourage programmers to begin by describing a taxonomy 
of classes (a high level concept) for use as low level data types. This approach can 
be criticized in a number of ways. First, the resulting tree structures are only a sub- 
set of the possible topologies that a program could have, and the implications of the 
restriction are unclear. Secondly, focusing on classes before a clear understanding of 
how they will be used as instances is obtained can lead to mistaken assumptions. In 
this paper we consider whether there is a natural program structure from the viewpoint 
of promise theory, a theory of declarations about what can happen between interacting 
components (as opposed to what is assumed to happen in particular use-cases). In such 
a short paper, it is not possible to fully justify such an idea, but we believe that the great 
simplicity of promise theory has virtue that is worthy of further study. The resulting 
viewpoint leads to a form of Service Oriented Architecture (SOA). 



2 A lightning introduction to promise theory 

Promise theory is a high level, graph-theoretical description of 'agents' which ex- 
hibit constrained behaviour. These agents are completely independent entities and 
they document the behaviours they expect to exhibit by making promises. Program- 
ming objects, functions and data will all be agents in our story. Agents in promise 
theory are truly autonomous, i.e. they cannot be forced into performing any service 
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of behaviour by external agents. Instead they voluntarily cooperate with one another 
| Burgess, 2005 1. This idea allows us to easily model unreliability and related issues by 
adding probabilities to promise graphs [Burg ess and Fagernes, a[ . Consider two agents 
a i and a%, where the first agent wishes to promise that it will behave according to a 
behavioural specification b. 

Definition 1 (Promise) An autonomous statement of , as yet, unverified behaviour, writ- 
ten: 

%:b 

fll > «2- (1) 

where b is the "promise body ". 

Agents are completely impenetrable to outside influence, they have private knowledge, 
and the promises that they make to one another cannot be coerced. A promise with 
body +b is understood to be a specification to "give" behaviour from one agent to 
another (possibly in the manner of a service), while a promise with body — b is a speci- 
fication of what behaviour will be "received" or "used" by one agent from another (see 

table [T]). A promise valuation v, ( a- s a^j is a subjective interpretation by agent ai 
(in any appropriate currency) of the promise in the parentheses. Usually an agent can 
only evaluate promises in which it is involved. 



Symbol 


Interpretation 


K:+b i 

a — > a 


Promise with body b 


I n:—b 

a > a 


Promise to accept b 


1 K:b ,n 

v a (a — > a ) 


The value of promise to a 


v fl ' (a — ► a ) 


The value of promise to a' 



Table 1 : Summary or promise notation 



Promises can be made about any subject that relates to the behaviour of the promis- 
ing agent, but no agent can make promises about another's behaviour. The subject of 
a promise is represented by the promise body b, which consist of two essential parts: 
a promise type (t) and a constraint (%) which indicates what subset of behaviours are 
promised from within the domain of all behaviours of that type. Finally, conditional 
promise bodies are written b/c, meaning that the body b is promised if the conditional 
c is promised. 

Promise theory is 'simpler' than the Unified Modelling Language, in that it has only 



one type of diagram (a labelled graph) and some simple algebraic rules | Burgess and Fage rnes, a) 
however many details are moved from diagrams into the definition of promise types 
and others are simply suppressed). This simplicity offers clarity and the discipline of 
voluntary cooperation reveals problems that are not apparent in obligation models of 
UML, as we show below. 

We define the concepts of a bundle and a role of promise types. We shall use this 
concept below to define a class in the object oriented sense. 

Definition 2 (Promise bundle) Let S,R C A be arbitrary subsets of equal dimension 
d,from the set of agents. A promise bundle is any collection of promises made (one-to- 
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one) from agents in S onto agents in R. We denote this 
a n-B %:b { %:b d 

S=^R = si — >n,...Sd, — >r d . (2) 

where II denotes a bundle of promises andB is the collection of promise bodies bi,b%, • • • ,bd- 

In promise theory, roles are associated both with types of promises X and their topology. 
In this respect, we can associate a collection of agents with a role, given that they make 
(or use) the same set of promise types. 

Definition 3 (Role) Let SI be a set of autonomous agents. The family of sender/receiver 
subsets S,R C si in a promise graph, which take part in promises with body types t(B), 
define B-roles. Any subset S or R in the graph is said to play a role of (sender/receiver) 
with body types t(B) in the promise graph. Bundles with equal types and different 
constraints have equal roles. 

Promise roles are identified empirically (as 'behaviour' must be), not 'designed' apri- 
ori. For instance, the set of all agent nodes W C si that promises to provide web service 

to any agent R G SI : W K -^$ (R e si) plays a role, which we can call 'web server' . The 

set of nodes C C A that is promised web service by any agent: (S € Si) C plays 
a role, which we can call 'web client'. We refer readers to [Burgess and Fagernes, a 
Burge ss~and Fagernes, b| for more information about promises and roles. 



3 PROGRAMMING CONCEPTS 

Modern programming methods rely heavily on compound types like 'record' or 'struct' . 
These are bundles of primitive data-types, hence bundles of promises about values. A 
class can additionally include methods as members. To save space, we state with- 
out proof an equivalence between methods and data values in promise theory. Since 
one can always write a method that simply returns a data value, we hope this is fairly 
intuitive. Using this equivalence of values and methods with promised services, we 
can now reinterpret OO-classes as collections of promise bodies from similar promise 
bundles. 

It is straightforward to map the structured class name tuples in fig. Q] to a flat 
promise type space. For instance, from figureQ] 

(XYZ,typel,namel) — > Ti, 

(XYZ,type2,name2) — > T2, 

(XYZ,type3,method(input)) — > T3/T4 

etc. (3) 

The hierarchical structure is not relevant to us; we only need to uniquely identify the 
members. It is thus trivial to model class instances or objects as bundles of promises 
that are isomorphic (see fig. [T). One of the controversial aspects of Object Oriented 
modelling is the idea that classes model real world situations and therefore lead to 
simpler programs. Let us take a different view, motivated by the idea of promises. 
Suppose we describe a program in terms of a set of promises it must keep: let us ask, is 
there a natural set of promise patterns that emerge in the promise graph of the program? 
Such basic patterns might be a natural set of classes for the program, or at least form 
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{ 

typel namel; 
type2 name2 ; 

type3 method (type4 input); 
} 

my_instance ; 

Tl 




Figure 1 : A class instance is a promise bundle with a unique pattern. 



a minimal spanning set. To explore this idea, we must establish a mapping between 
promises and OO concepts. 

We assume here, for simplicity, that we are operating in a region of common data 
types and map promise types to data types. 

Definition 4 (Class-like promise body) Any unique collection of promise bodies c = 
{b\,b2, ■ ■ ■}, belonging to a promise bundle. 

A class-like bundle is a collection of promise bodies, i.e. it is missing the sender and 
the receiver. It is thus an abstract compound type. 

In other words, class-like instances form distinguishable patterns of promises, that 
occur possibly several times in the graph and they must agree on the basic type-alphabet 
for their pattern matching, on a per-promise basis. A class-like bundle could now 
naturally be associated with an OO class, and the OO-class is thence the role belonging 
to a promise bundle. However, we must remember that the naming of classes in OO is 
a user policy decision, not a requirement. Thus, we claim that while the roles lead us 
to a 'natural' set of classes, there is no obligation for any programmer, agent or analyst 
to adopt these as the actual set of OO classes. What we have identified is a natural 
'spanning set' of class containers. This emphasizes that OO is a policy, not a necessity. 



3.1 Inheritance and usage 

The concept of inheritance is central in Object Orientation, but it is often ambigu- 
ously described. It is both used and explained using a number of different interpreta- 
tions |Snyde^T986, Lieberman, 1986 Cook, 1989]. We can use promises to restate the 



meaning of inheritance more clearly, though we cannot claim that our interpretations 
are those intended by other authors. We shall consider three such meanings: 

• Class 2 extends (adds to) class 1: 

When a child class extends another parent class, it adds values and methods that 
were not present in the parent class. 

• Class 2 substitutes ( replaces) class 1 

When a child class substitutes a parent class, it replaces it completely with a new 
implementation. In the case of an abstract parent class it might, in fact, provide 
the first proper implementation. 
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• Class 2 specializes (overrides) class 1: 

A subset of values and methods in the parent class can be replaced with new 
implementations. In the limit of complete overriding, this becomes the same as 
substitution. 

Programming languages generally lump all three inheritance meanings together in a 
general construct, so an inheritance policy might imply several of these at the same 
time (e.g. one often extends a parent class into a number of child classes which are 
then thought of as specializations - here we would call them mutually exclusive exten- 
sions). We wish to be somewhat clear about these and therefore keep them separate. In 
addition to this there is usage or delegation in which a class "out-sources" functionality 
to other classes by aggregation of multiple specialized classes. This is similar in spirit 
to extension, but does not attempt to "philosophically" integrate the functionality under 
the umbrella of the same class. 

The choice of inheritance and delegation is a policy choice, often motivated by 
a heuristic philosophy. The Liskov Substitution Principle (Class 2 "IS A" Class 1) 
has often been used to explain when inheritance should be used over delegation, for 



instance | Liskov and Wing, 1993 1. However, the "is a" relationship is itself a heuristic 
one, in which it is unclear whether one is talking about syntax or behaviour. This leads 
to ambiguities in its application. Inheritance is thus used with several inequivalent 
meanings in OO, and so we must disentangle the semantics of these distinct policies as 
behavioural promises. 

Extension is a relationship that decides whether a parent class is a subset of the 
derived child class. Let us define these in terms of promises. 

Definition 5 (Extension) Let c and d be two class-like bundles, We say that c extends 
d or c > d iff d C c. This gives us the notion of a container, and containment. 

Notice that this is simply a rule for aggregation. In terms of promises, there is no 
difference between the extension of a class and the formation of a bundle. 

Overriding promises (methods and values) is typically a technique used in sub-type 
polymorphism. When overriding, there cannot be a conflict between parent and client 
by definition, since the new behaviour and the old behaviour are mutually exclusive. 
Overriding requires a switch-like structure (indeed subtype-polymorphism is often in- 
tended to replace switch-case constructions). Let S and R be agents, promise bundles 
can be selected and hence overridden based on type labels using a construction in which 
bundles are made exclusively if a certain type is promised. Since types are mutually 
exclusive, the promises are mutually exclusive: 

n:ci/type=typel ^ 
n:c 2 /type=type2 ^ 



R 



7i:type 



S *^ R (4) 

Specialization is a selective use of overriding to alter a subset of promises. 

Definition 6 (Specialization) Let c p and ci, i = 1 . . .N be class-like bundles. We say 
that Ci specializes c p iff a subset c C c p of class promises in the bundle is made condi- 
tionally on predicate p and all promises in ci are dependent on predicates pu in such 
a way that p and pj are all mutually exclusive. It is normally assumed that the promise 
types in c p and c; are identical. 
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Thus we define a polymorphic class replacement using a simple switch-case construc- 
tion as one would expect. 

For example, consider promise bundles that belong to the parent and the child. 
These are conditionally switched if the promise of a subtype is made by the receiving 
agent. 

n.c'[ );ise _p aren ( 
o R 

_ n:c cxl _p arcn t/-'subtype . 

S =^> R (optional) 

n:f chi[d /subtype 
^ 71 : subtype 

S ^^») * (5) 

Here the extension-parent class bundle is exchanged for the child bundle if subtype is 
promised. The base-parent bundle is promised in both cases. If a parent class wishes 
to enforce behavioural constraints on a child, then it must make such base-promises 
that are not overridable, otherwise there can never be any broken promises in spite of 
radically changing behaviour. 

Specialization is a selective use of overriding to alter a subset of promises. 

Definition 7 (Substitution) Let c p and cu i = 1 . . . N be class-like bundles. We say that 
Ci substitutes c p iff the body c p in the bundle is made conditionally on some predicate 
p and all promises in C[ are dependent on predicates pu in such a way that p and pi 
are all mutually exclusive. It is assumed that c p and c,- are isomorphic with respect to 
promise types and number, so that every ci is a complete replacement for c p . 

Through these definitions we have unwittingly shown how to implement ontological 
mappings for OO within the Service Oriented Architecture (SOA) through type agree- 
ment. This is not something easily represented in UML. 



4 THE LISKOV TEST 

Our notion of substitution is stronger than the weak form often used in the literature. 
The Liskov substitution test |Liskov and Win g, 1993) was originally proposed as a syn- 
tactic and semantic guideline on "good inheritance" and attempted to summarize and 
make sense of the practice of inheritance by introducing a test of class compliance. 
The test has since often been represented by the introduction of the heuristic "is a" 
relation, whose name seems to imply an equality of certain entities, but this is not the 
case. Unfortunately this term is rarely given a clear definition and therefore leads to 
confusions and apparent paradoxes. We shall make simple sense of this relation with 
our own definition as follows: 

Definition 8 ("is a") A class-like promise bundle S => R "IS A" class-like promise 

Tic' 

bundle S => R iff both bundles can be promised at the same time without breaking any 
promises. 

An example that is frequently used to illustrate an apparent paradox with this is that 
of a rectangle and a square. Clearly a square is a special case of a rectangle as a concept, 
in every mathematical sense, however a square has fewer behavioural freedoms than a 
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rectangle (not more) so it cannot extend the notion of rectangle in behavioural terms. 
This indicates that extension is often at odds with the notion of specialization. We can 
see this as follows. Let R be a rectangle agent, S be a square agent and A be any other 
promisee agent. 

„ jr:width=vv . 

R — > A 

7r:h eight =/i 
7i:angle=9Q 

R n:s ^r 4 A (6) 
We assume they have a common data-type schema, so we let square extend rectangle: 



5 


Jt:width=vv 


A 


S 


Jt:height=/i 


A 


S 


7i:angle=90 


A 


s 


7i:sides=4 


A 


s 


7i\W=h 


A 



(7) 

The only difference now is that an additional promise has been made. This is a be- 
havioural constraint (not easily implementable in a programming language, but straight- 
forward in terms of promises). Now, since the promises 

^ JT:width— w ^ 

7i:height=/i ^ 

S ^ A (8) 
are not independent, they may be reduced to: 

c 7i:width=/7 , 

S K±e ^" A. (9) 

And if we now try to ask the question whether square "is a" rectangle, it implies that 
all promises of S and R must hold simultaneously. However, we quickly find a broken 
promise: 

S/R K:v ^F w R 

S/R K±agh l =h R. (10) 

Hence a square "is not a" rectangle in terms of the behaviours we have attributed to it. 
To avoid this problem one can simply introduce a programming policy, "Parent bundle 
promises should never be broken by a child bundle". 



5 A 'NATURAL' MODELLING EXAMPLE 

Consider now a scenario in which the Unified Modelling Language (UML) leads to a 
problematic solution, with little guidance to see what is going wrong [ |Aredo, 2004| . 



7 



Consider a bank, comprised of a number of employees and accounts for customers. 
Bank customers should have access to use their accounts and bank employees are able 
to make certain privileged transactions on accounts. If some customers are in fact bank 
employees, they should not have privileged access to perform transactions that include 
their own accounts (since this could lead to embezzlement). Any user/Person, whether 
the owner of an account or not should be able to make a cash payment to any account. 
This example is somewhat simplistic, but therefore also uncomplicated; however, it 
illustrates the basic conundrum. 

A not-unnatural UML model of this scenario is shown in fig. [2] We introduce the 
parent class "Person" from which two child classes are derived by inheritance. UML 
makes associations between classes and in UML a subclass inherits associations, as 
these form a subset of general attributes. Given only this guidance, one could easily 
be led to the model shown in fig. [2] This structure has two problems that are easily 
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1.* 1.. 



Bank 
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1. 



Person 



I 



updates 



Ancount 



Customer 




Employee 















Figure 2: An 00 class model for the bank account/user interaction, in UML. 



avoidable by reorganizing the model, but which are not ruled out by UML: 

1. It assumes that customers and employees are mutually exclusive categories. 

2. It allows employees to perform privileged updates on their own accounts. 

Although these are undesirable properties UML semantics do not offer sufficient guid- 
ance to see what is going wrong. 

Now consider a promise approach. We introduce agents for users, bank accounts 
and also a single (optional) agent representing the bank's administration. Always bear- 
ing in mind that agents in promise theory cannot be forced to perform any function, and 
have limited knowledge, we identify the necessary promises from Users to Account 
agents. We further introduce a category attribute for users of accounts: "customer", 
"employee" and the default "other". The categories "customer" and "other" are dis- 
joint. We assume one account per agent and one user/Person per agent. To transport 
the necessary information to make promise-theoretic decisions, a user/Person-agent 
must identify itself and its category. The possible set of promises that are common to 
all agents are: 



Person 



n:name=identitv 



Account (general) 
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Kxash payment , . 

Person — ► Account [general) 



Person 
Person 



■n:customer 



%:employee 



Account (subset) 
Account (subset) 



(11) 



Some promises probably only make sense for certain categories of agent and we might 
represent these as conditional promises: 



%:use account /customer 

Person — ► Account 

w.priv update I employee 

Person — ► Account 



(12) 



however, one could imagine that dishonest agents might try to make these promises 
unconditionally. It is entirely up to the receiving account to deal with such behaviour, 
according to the promise precepts, so we shall disregard the conditionals here, as they 
make an unwarranted assumption about agent behaviour. Note that an agent which 
does not promise to be a customer or an employee can still exist and make promises, 
such as cash payments to any account. Privileged updates, on the other hand, should 
only be promised by employees. 

An account agent makes a number of promises to users in return; some of these are 
of a general nature, such as accepting information promised to the agent: 



Account 


71: U (name=id entity) 


Person 


Account 


n:U (employee) 


Person 


Account 


K:U (customer) 


Person 


Account 


K.Keep money safe 


Person 


Account 


wAccount functions 


Person 


Account 


K:U(cash payment) 


Person 



(13) 



Some additional promises are conditional on the category of user, such as the promise 
to accept instructions from different user categories. This leads us naturally to an im- 
plementation in terms of access control rather than class inheritance. 

n:U(use account )/C\ 

Account — ► Person 

%:U{priv update) I C 2 

Account — ► Person (14) 

Let us consider these conditions. Any agent can make a cash payment to an account, 
regardless of privilege level. For other transactions, we want to ensure authorization 
however. The owner of an account should have all normal usage privileges, thus if an 
agent with a name matching. The conditions C\,C2 must be based on information that 
is available (promised) to the account agents: 

C\ : name = owner AND employee ^ true 

C2 ■ name ^ owner AND employee = true (15) 

These conditional promises are mutually exclusive and hence they should be repre- 
sented by exclusive promises, which extend the unconditional promises to accept cash 
payments. 
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We allow user/Person agents to be both customers and employees non-exclusively, 
since the conditional tests can be made based entirely on the information that a user 
is operating in employee mode (e.g. making that promise by entering an authorization 
code or passwd). We see from the services provided by an account that users are 
distinguished entirely by the functions they carry out, not by named skills without a 
basis in actual behaviour. 

Account-agents promise to accept normal usage transactions as long as an agent is 
not an employee (any agent customer or not might need to pay money into a customer's 
account). An agent who is sometimes an employee can also use its account as long 
as it is not currently making the employee promise. As soon as employee privilege is 
invoked, account agents invoke different promised behaviour which restricts the actions 
they can perform. 

What about the UML ownership association? The account attribute "owner" is the 
private knowledge of the account-agent concerned. There is no need for this informa- 
tion to be issued as an explicit relation that is promised to a user, since that behaviour is 
implicit in the Use-promises. Thus the "owns" association is not a necessary interface 
relation, only an attribute of the account. 

Readers might be uncomfortable that a bank account somehow knows ownership 
information by itself - this is not how many would view a traditional bank. If we 
wish to model a more traditional, centralized bank, we could introduce a central bank 
agent which has knowledge of all accounts and delegates the data to its subordinate 
account-agents: 

Bank IlJ ^>'°' Account,-, Vz (16) 

Similarly, the account-agents could place themselves under the umbrella of the bank 
by promising to use these names from the central bank agent. 

%:U(Namei) 
Account,- — > Bank 

, n:K mmK =Name i 

Account, — ► Bank (17) 

There is nothing in this model that requires this however. If one were to implement 
a bank as a Service Oriented device, then bank accounts could be created anywhere 
without a common umbrella. They do not have to belong to a single bank. Our model 
is rather too primitive to make a detailed case for this here however. 

5.1 The roles and classes 

We conjectured that the natural spanning set of classes in a system can be discovered 
by looking for roles in the promise graph, i.e. common and repeated patterns within the 
graph. When role-promises are disjoint or mutually exclusive they fall naturally into 
separate sub-classes, such as might be implemented through sub-type polymorphism 
in OO. The solution below is shown in fig. [3] 

We recognize three kinds of account promise roles, two of which are mutually 
exclusive (and hence form natural subtypes) and one which is common to the others 
(and hence requires no subtype). This forms a natural tree decomposition as shown in 
fig. SI 

What we see is that the promise theory solution, which makes behaviour the pre- 
mier consideration, is to split the account class into two rather than the person/user 
class. The split is based on what promises are available to the different kinds of users. 
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Person 



Account 



String name 
Bool customer 
Bool employee 
Pay cash -payment 



U(name) 
U (customer) 
U(employee) 
U(cash payment) 
Account functions 
Keep money safe 



CustomerACInt 
U(use account) 



EmployeeACInt 
U(priv update) 



Figure 3: A promise role derived class structure for the bank account problem. Note that the 
customer/employee roles are not represented as separate classes, but as attributes to the common 
user (Person) class. 




Figure 4: Taking a promise viewpoint, the roles in the bank account interaction example are 
shown. Note that different user roles overlap. An employee might also be a customer in the 
bank, similarly user can pay in transactions even when a user is not a customer of the bank. 



The change to an account subtype is a change in security level (like a pure Clark- Wilson 
model [Cla rk and Wilson, 1987 1 interface) which leads to a natural access control. We 
end up with two security levels, implemented through mutually exclusive interfaces 
(modes) in the account class, rather than two kinds of users, since this arrangement 
embodies the behavioural constraints. 



6 DISCUSSION AND CONCLUSION 

We do not know of any work truly related to the idea of promises, though some super- 
ficially similar ideas exist in multi-agent theory [Wooldridge, 2002]. There is clearly a 



large literature on program modelling but not from the perspective of voluntary coop- 
eration. 

Using our notion of promises, we are able to model some salient features of pro- 
gram modelling and offer guidance to the avoidance of common problems. There is 
an enormous potential for describing interfaces and constraints on program activities, 
without having to deal with actual computational processes. Another programming 
paradigm introduced recently is that of aspects. Aspects allow one to weave in-line 
code fragments into an existing program using a secondary compiler. The break with 
the hierarchical container idiom makes this awkward to model in a class regime, but 
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this is easily represented as promises or services performed by a weaving agent. 

In OO design one models data-types first and creates instances of these pre-decided 
types on demand as program logic develops. This seems natural, since one does not 
necessarily know what precise objects will be required in advance; however, it can lead 
to blind alleys and refactoring, as one has no empirical basis for a project at the outset. 
A spanning set model, based on required objects and their promises, which leads to 
'natural' organizational structures, can help to avoid some of these blind alleys. We 
have applied this approach to code examples in cfengine 3 [Burgess, 1993] with some 
success. 

Promises also allow analyses, both logical and economic. The economic trade- 
like model inherent in the SOA is naturally described in promise theory. Using the 
idea of common knowledge as a graph theoretic construction (rather than a modal 
logic inference) one has an easy way of tracking scope with graph theoretical tools 
| Aredo and Burgess, 2007]. This could be an approach to examining reflections, or 
'self-aware' programs. There are other ways entirely in which promises might assist 
in modelling software engineering. The act of basing software on a specification is a 
promise to customers, saying that a program will comply with its specification. On the 
other hand, much software is developed without any formal specification. Does this 
make it less able to function reliably? 

What role do we foresee for promises in program modelling in the future? There are 
several possibilties. In cfengine 3, promises have been made into a computer language 
for high level policy declaration. It would be straightforward to add more user-friendly 
graphical tools to rival the simplicity of UML, allowing policy to encompass program 
structure more readily. Promises clearly make SOA thinking easier, so they are a nat- 
ural tool for programmers there (independently of web services). More importantly, 
we believe that promises offer a flexible way of thinking that is at least as powerful 
as hierarchical classes but which is less "brittle" and therefore more robust to errors 
regardless of their source. 

UML claims to model behaviour, but in fact it only describes assumed internal 
transitions. Behaviour is something that must be observed once a program is operat- 
ing in its environment, and since the environment is not modelled, behaviour is not 
modelled. This distinction is clearer in promise theory and so there is some hope 
that phenomena such as emergent behaviour can be understood in this framework 
| Burgess and Fa gernes, 2007) . We are developing these issues in other work. 
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